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Background 

Field of Invention 

[0002] The present invention relates generally to dynamically configuring 
user software licenses, and more specifically to using dynamic hardware profiles to 
distinguish legitimate hardware upgrades fi*om unauthorized installation of software 
programs on additional computers. 

Background of Invention 

[0003] Software piracy is very prevalent, and causes a significant loss of 
potential revenue for software vendors. For this reason, many software vendors require 
that a user activate a software license before operating a software program. Typically, 
the software vendor will provide a unique identifier with each copy of the software. In 
order to run the software, the user must provide that identifier to the vendor (either via 



the Internet, by telephone, or some other way). The vendor associates the identifier with 
the specific user, and stores a record of that association, typically in a database or the 
like. The vendor then activates the user's copy of the software, either automatically over 
the Intemet, or by providing the user with an activation code to enter manually. 
Typically, activation involves updating a Hcense file on the user's computer, to indicate 
that the software is activated. Whenever the software program runs, it checks the license 
file, and only runs if the software has been activated. 

[0004] Such a system fails to prevent a user fi:om making unauthorized 
copies of the software program, once the software program has been activated. Because 
the activation is performed once, and a record of the activation is kept on the user's 
computer in the form of the updated (activated) license file, the user can install the 
software program on a second user's computer, by simply copying the complete contents 
of the folders that hold the installed software program. Because this will copy the 
activated license file as well as the software program, the second user will now be able to 
run the software program. Such unauthorized copying is known is "pass along piracy." 

[0005] One method used to prevent pass along piracy is to include a 
hardware profile of the user's computer in the license file. During the activation process, 
the software program can scan the hardware of the computer of the authorized user. 
Then, a profile of the hardware configuration can be stored in the activated license file. 
When the software program is subsequently run, it can not only check to see if an 
activated license file is present, but can also check to see if the hardware of the computer 
it is running on corresponds to that of the authorized user. The software program does 
this by scanning the hardware of the computer it is running on, and comparing the resuft 
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to the hardware profile of the authorized user in the hcense file. Only if the hardware is 
the same or within an acceptable margin of difference will the software program run. 
That way, if the user installs an unauthorized copy of the software program on a second 
user's computer, when the second user tries to run the software program, the software 
program deteraiines that it is installed on an unauthorized computer and can thereby 
block unauthorized use. 

[0006] One problem with such a methodology is that it does not allow an 
authorized user to upgrade his hardware. For example, if an authorized user changes 
hardware components of his computer (e.g. changes the monitor, adds a cable modem, 
adds memory), the current hardware will no longer match the stored hardware profile and 
the software program will not run. Additionally, the same problem will occur if the 
authorized user pxirchases a new computer, and wishes to transfer the software program 
firom the older computer to the new one. 

[0007] Some software vendors allow a user to call on the telephone and 
inform the vendor of such changes. If the vendor is convinced that the user really has 
modified his hardware configuration or purchased a new computer, the vendor can 
activate the software on the new or modified computer. However, the vendor has no way 
of knowing whether the user has really made a legitimate hardware modification, or 
whether the user is attempting to make an unauthorized copy of the software. Suppose 
that the user has actually engaged in pass along piracy, by installing the software on a 
second user's computer. If the user convinces the vendor that the new installation is 
legitimate, the vendor will unknowingly activate the software on the second user's 
computer. Because the software has aheady been activated on the first user's computer, 
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nothing stops the first user from continuing to run the software on his computer, while the 
second user runs the pirated software on a second computer. On the other hand, if the 
user has legitimately upgraded his computer but cannot convince the vendor, the user will 
not be able to run the software product at all. 

[0008] Thus, existing software Ucensing activation methods either do not 
adequately prevent pass along piracy, or can prevent an authorized user from running the 
software product on his own computer, after making legitimate hardware modifications. 
What is needed are methods, systems and computer readable media for that can detect 
and prevent pass along piracy, yet allow licensed users to make legitimate hardware 
modifications to their own computers. 

Summary of Invention 

[0009] In some embodiments, a user runs a client software program on a 
computer. As the user runs the software program, the user attempts to access various 
features of the software program. Requests to access features of the software program 
are transmitted to a server. Such requests include user identification infomiation and 
license verification information including a hardware profile of the computer on which 
the user is attempting to run the software. 

[0010] The server maintains user software license information, including the 
hardware profile of the computer on which the user is authorized to run the software 
program, and the date of the most recent modification of that hardware profile. 
Responsive to receiving a request, the server retrieves stored license information for the 
user, and determines whether the received hardware profile is identical or acceptably 
similar to the stored, authorized hardware profile. 
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[0011] If the received and stored hardware profiles are identical, the server 
concludes that the user is authorized to run the software, and responds to the request 
accordingly. If the received profile is acceptably similar to the stored profile but not 
identical, the server determines whether the difference could be the result of an 
authorized hardware upgrade. Because legitimate upgrades are only performed with 
limited firequency, the server compares the current date to the stored date indicating the 
last authorized modification. If the current date is sufficiently later, the server determines 
that the user has performed an authorized hardware upgrade. In response, the server 
updates its stored hardware profile and associated modification date according to the 
currently detected upgrade, and sends a verification to the client that the user is 
authorized to run the software program. In some embodiments, if the received hardware 
profile is acceptably similar to the stored hardware profile but the current date is not 
sufficiently later than the stored modification date, the server sends an authorization 
verification to the client, but does not update its stored hardware profile, thereby allowing 
the user some flexibility while still ensuring a requisite level of security. In other 
embodiments, the server determines that the user is attempting to run the software on an 
unlicensed computer, and retums an appropriate indication to the client. If the received 
hardware profile is neither acceptably similar nor identical to the stored hardware profile, 
the server determines that the user is attempting to run the software on an unlicensed 
computer, and retums an appropriate indication to the client. 

[0012] The features and advantages described in this summary and the 
following detailed description are not all-inclusive, and particularly, many additional 
features and advantages will be apparent to one of ordinary skill in the art in view of the 
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drawings, specification, and claims hereof. Moreover, it should be noted that the 
language used in the specification has been principally selected for readability and 
instructional purposes, and may not have been selected to delineate or circumscribe the 
inventive subject matter, resort to the claims being necessary to determine such inventive 
subject matter. 

Brief Description of the Drawings 

[0013] Figure 1 is a block diagram providing a high level overview of a 
system for dynamically managing software license information that includes a hardware 
configuration identifier and hardware configuration identifier modification date, 
according to some embodiments of the current invention. 

[0014] Figure 2 A is a flowchart, illustrating high level steps for processing 
cUent requests including hardware configuration identifiers, according to some 
embodiments of the present invention. 

[0015] Figure 2B is a flowchart, illustrating steps for processing cUent 
requests where the current date is sufficiently later than the stored hardware configuration 
identifier modification date, according to some embodiments of the present invention. 

[0016] Figure 3 is a flowchart, illustrating steps for processing client 
requests where the current date is not sufficiently later than the stored hardware 
configuration identifier modification date, according to some embodiments of the present 
invention. 

[0017] Figure 4 is a flowchart, illustrating steps for server side processing of 
client requests, where the received hardware configuration identifier and the stored 
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hardware configuration identifier are identical, according to some embodiments of the 
present invention. 

[0018] Figure 5 is a flowchart, illustrating steps for server side processing of 
client requests, where the received hardware configuration identifier is not acceptably 
similar or identical to the stored hardware configuration identifier, according to some 
embodiments of the present invention. 

[0019] Figure 6A is a flowchart, illustrating high level steps for client side 
processing according to some embodiments of the present invention, in which the client 
makes a supplemental check that the user is licensed to run the software program on the 
computer on which the program is currently executing. 

[0020] Figure 6B is a flowchart, illustrating steps for cUent side processing 
where the current date is sufficiently later than the received hardware configuration 
identifier modification date, according to some embodiments of the present invention. 

[0021] Figure 7 is a flowchart, illustrating steps for client side processing 
where the current date is not sufficiently later than the received hardware configuration 
identifier modification date, according to some embodiments of the present invention. 

[0022] Figure 8 is a flowchart, illustrating steps for client side processing 
where the received hardware configuration identifier is identical to the current hardware 
configuration identifier, according to some embodiments of the present invention. 

[0023] Figure 9 is a flowchart, illustrating steps for cUent side processing 
according to some embodiments of the present invention, where the current hardware 
configuration identifier created by the client is not acceptably similar or identical to the 
hardware configuration identifier received firom the server. 
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[0024] Figure IDA is a flowchart, illustrating high level steps for cHent side 
processing according to some embodiments of the present invention in which the cHent 
performs a validation check upon starting the software program. 

[0025] Figure 1 OB is a flowchart, illustrating steps for client side processing 
where the current date is suflBcienfly later than the stored hardware configuration 
identifier modification date, according to some embodiments of the present invention in 
which the client performs a vaUdation check upon starting the software program. 

[0026] Figure 1 1 is a flowchart, illustrating steps for client side processing 
where the current date is not sufficiently later than the stored hardware configuration 
identifier modification date, according to some embodiments of the present invention in 
which the client performs a validation check upon starting the software program. 

[0027] Figure 12 is a flowchart, illustrating steps for client side processing 
when the current hardware configuration identifier is identical to the stored hardware 
configuration identifier, according to some embodiments of the present invention in 
which the client performs a vaUdation check upon starting the software program. 

[0028] Figure 13 is a flowchart, illustrating steps for client side processing 
when the current hardware configuration identifier is not acceptably similar or identical 
to the stored hardware configuration identifier, according to some embodiments of the 
present invention in which the cUent performs a validation check upon starting the 
software program. 

[0029] The figures depict embodiments of the present invention for 
purposes of illustration only. One skilled in the art will readily recognize fi:om the 
following discussion that alternative embodiments of the structures and methods 
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illustrated herein may be employed without departing from the principles of the invention 
described herein. 

Detailed Description 

[0030] Figure 1 provides a high level overview of a system 100 for 
dynamically managing software license information 101 that includes a hardware 
configuration identifier 1 10 and a hardware configuration identifier modification date 
111, according to some embodiments of the present invention. A user 102 runs a client 
103 software program on a computer 104. As the user 102 runs the software program 
103, the user 102 attempts to access features 105 of the software program. Some features 
105 are provided by a server 108, in which case the client 103 makes requests 107 to the 
server 108 to access the features 105. Other features are provided locally by the client 
103 without the need to access the server 108. In some embodiments of the present 
invention, the client 103 is configured such that the user 102 attempting to access a client 
103 provided feature 105 triggers a request 107 to the server 108, such that the server 108 
can dynamically configure the user's software license information 101 as described 
herein. Which features 105 of the software program result in such a request 107 is a 
design choice, which can vary from embodiment to embodiment as desired. 

[0031] Client 103 requests 107 include identification information 109 
conceming the user 102, and a hardware configuration identifier 110. The format of the 
user identification information 109 can vary from embodiment to embodiment. In some 
embodiments, the user identification information 109 comprises a unique identifier 
provided by the software vendor with the user's copy of the software. Various formats of 
user identification information 109 will be readily apparent to one of ordinary skill in the 
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relevant art. The fonnat of the hardware configuration identifier 1 10 is discussed in 
greater detail below. 

[0032] As used herein, the term client 1 03 simply denotes those aspects of 
the software program associated with a user's computer 104, as well as underlying 
operating system and hardware support. As will be understood by those of skill in the art, 
a client 103 within the context of the present invention can comprise components of the 
software program, as well as components of the operating system of a user's computer 
104 and hardware components of a user's computer 104. 

[0033] As used herein, the term server 108 simply denotes those aspects of 
the software program associated with a remote computer, as well as underlying operating 
system and hardware support. As will be understood by those of skill in the art, a server 
108 within the context of the present invention can comprise components of the software 
program, as well as components of the operating system of a remote computer 104 and 
hardware components of a remote computer 104. 

[0034] The server 108 receives requests 107 from the client 103 to access 
features 105 of the software program. Although Figure 1 illustrates two requests 107 
being transmitted by a cUent 103 to a server 108, the number two is of course only an 
example. One of ordinary skill in the relevant art will readily understand that over a 
period of time, the client 103 can make a variable number of requests 107 as desired. 

[0035] Responsive to receiving a request 107, the server 108 retrieves stored 
software license information 101 concerning the user 102. The server 108 can utilize the 
user identification information 109 to locate the stored software license information 101 
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in a maimer that will be readily apparent to one of ordinary skill in the relevant art, in 
light of this specification. 

[0036] In the embodiments illustrated in Figure 1, the client 103 includes a 
current hardware configuration identifier 1 10 with each request. Using techniques that 
will be readily apparent to one of ordinary skill in the art, the client 103 can create a 
hardware configuration identifier 1 10 that corresponds to the hardware configuration of 
the user's computer 104. The hardware configuration identifier 110 need not be a 
detailed listing of the complete hardware configuration of the user's computer 104, but 
contains information representing a sufficient number of hardware components to 
identify a computer 104 by its hardware configuration. One of ordinary skill in the 
relevant art will readily understand that various formats are possible for the hardware 
configuration identifier 1 10, for example a hash of selected components. The selection 
and number of components to include, as well as the format, are design choices. 

[0037] The stored license information 101 on the server 108 includes a 
hardware configuration identifier 110 concerning the user's computer 104, as well as an 
associated hardware configuration identifier modification date 1 1 1 . In some 
embodiments, the user's hardware configuration identifier 1 10 is stored by the server 
when the user's software Ucense is first activated. Initially, the modification date 1 1 1 is 
set to the current date 113 at the time the user's software license is initially activated. 
Subsequently, the stored hardware configuration identifier 1 10 can be updated, as 
explained below. When the stored hardware configuration identifier 1 10 is modified, the 
associated modification date 1 1 1 is updated as well, to reflect the date of the 
modification. 
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[0038] Figure 2 A illustrates high level steps for processing client 1 03 
requests 107 including hardware configuration identifiers 110, according to some 
embodiments of the present invention. The steps illustrated at a high level in Figure 2A 
are described in detail in conjunction with Figures 2B through 5. 

[0039] Figure 2B illustrates steps for processing client 103 requests 107 
where the current date 1 13 is sufficiently later than the stored hardware configuration 
identifier modification date 111 according to some embodiments of the present invention. 
When the server 108 receives 201 a request 107, the server 108 retrieves 203 stored 
license information 101 concerning the user 102, the stored license information 101 
including a hardware configuration identifier 110 concerning the user's computer 104 and 
an associated modification date 111. The server 108 then compares 205 the received 
hardware configuration identifier 1 10 to the stored hardware configuration identifier 110, 
to determine whether the received hardware configuration identifier 1 10 is acceptably 
similar to the stored hardware configuration identifier 110. Recall that when the user's 
software license was activated, the server 108 stored what was at that time a current 
identifier 110 of the hardware configuration of the user's computer 104. The received 
request 107 includes an identifier 1 10 of the hardware configuration of the user's 
computer 104 at the time the request 107 was transmitted. By comparing 205 the stored 
hardware configuration identifier 1 10 to the received hardware configuration identifier 
1 10, the server can determine whether or not the software program is being run on a 
licensed computer 104. 

[0040] It is to be understood that the definition of "acceptably similar" is a 
design choice, which is a function of to what extent hardware modifications will be 
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pennitted without triggering a detennination of a new computer 104. In different 
embodiments varying amounts of difference are tolerated, as desired. For example, in 
some embodiments a specific number of hardware components must be identical for the 
two identifiers 1 10 to be considered acceptably similar. 

[0041] If the received hardware configuration identifier 1 10 is acceptably 
similar but not identical to the stored hardware configuration identifier 1 10, the server 
108 compares 207 the stored modification date 1 1 1 with the current date 113. Because 
the received hardware configuration identifier 1 10 is not identical to the stored hardware 
configuration identifier 1 10, the server 108 has detected that the user's 102 hardware 
profile has been updated. The received hardware configuration identifier 1 10 is 
acceptably similar to the stored hardware configuration identifier 1 10, indicating a 
hardware upgrade by the user 102, as opposed to installation of tiie software on a new 
computer 104. Nonetheless, it is desirable for tiie server 108 to determine how long it has 
been since the user's 102 last hardware upgrade. This is because even acceptable 
hardware upgrades are only permitted every so often. If users 102 were allowed to make 
an unlimited number of hardware upgrades at an unrestiicted fi-equency, users 102 could 
move software firom computer to computer by moving hardware components between 
computers 104 in succession, generating online requests 107 after each reconfiguration. 

[0042] Thus, the server 108 only concludes that tiie request was generated 
from a licensed computer 104 if tiie current date 1 13 is sufficiently later tiian tiie stored 
hardware configuration identifier modification date 1 1 1 . In this case, the server 108 
updates 209, 211 the stored software license information 101 concerning tiie user 102 by 
replacing the stored hardware configuration identifier 1 10 with the received hardware 
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configuration identifier 1 10, and by replacing the stored hardware configuration identifier 
modification date 1 1 1 with the current date 113. Thus, the server has recorded the 
current hardware profile of the user's 102 computer, along with the date that the server 
108 detected the hardware upgrade. This information can be used by the server for 
subsequent user 102 license verification. The server 108 returns 213 software license 
information 101 concerning the user to the cUent 103, indicating that the user 102 is 
licensed to run the software. This license information includes the updated stored 
hardware configuration identifier 1 10 and, in some embodiments, its associated 
modification date 111. This information can be used by tiie client 103 for additional 
verification, as discussed below. 

[0043] It is to be understood tiiat the definition of "sufficiently later" is a 
design choice, which is a fimction of how often modifications will be permitted without 
triggering a determination of a new computer 104. Li different embodiments, various 
modification frequencies are tolerated, as desired. 

[0044] Figure 3 illustrates steps for processing client 103 requests 108 
where the current date 113 is not sufficiently later tiian the stored hardware configuration 
identifier modification date 111, according to some embodiments of the present 
invention. As explained above in conjunction with Figure 2B, the server 108 receives 
201 a request 108, retrieves 203 stored license information 101 concerning the user 102 
and compares 205 the received hardware configuration identifier 1 10 to tiie stored one 
1 10. Responsive to the received hardware configuration identifier 1 10 being acceptably 
similar but not identical to the stored hardware configuration identifier 1 10, the server 
108 compares 207 the stored modification date 1 1 1 with the current date 1 13. Whqre the 
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current date 1 13 is not sufficiently later than the stored hardware configuration identifier 
modification date 1 1 1, in some embodiments the server 108 determines 301 that the user 
is not licensed to run the software program, and therefore returns 303 software license 
information 101 so indicating to the client 103 (as illustrated in Figures 2A and 3). In 
other embodiments, the server 108 sends license information 101 to the client 103 
allowing the user 102 to run the software, but the server 108 does not update the stored 
software license information 101 concerning the user 102 by replacing the stored 
hardware configuration identifier 1 10 with the received hardware configuration identifier 
1 10, or by replacing the stored hardware configuration identifier modification date 1 1 1 
with the current date 1 13 (not illustrated). Such embodiments allow the user 102 some 
flexibility while still ensuring a requisite level of security. 

[0045] Sometimes, the received hardware configuration identifier 1 10 and 
the stored hardware configuration identifier 1 10 will be identical. Figure 4 illustrates 
steps for server 108 side processing of client 103 requests 108 under those circumstances, 
according to some embodiments of the present invention. The server 108 receives 201 a 
request 108, retrieves 203 stored Hcense information 101 concerning the user 102 and 
compares 205 the received hardware configuration identifier 1 10 to the stored identifier 
1 10. Responsive to the received hardware configuration identifier 110 being identical to 
the stored hardware configuration identifier 1 10, the server 108 returns 401 license 
information 101 indicating that the user 102 is licensed to run the software. Because the 
hardware configuration identifier 1 10 received with the request 108 is identical to the one 
stored by the server 108, the server 108 is able to conclude that the request 108 originated 
from a hcensed computer 104. 
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[0046] Of course, sometimes the received hardware configuration identifier 
1 10 is not acceptably similar or identical to the stored hardware configuration identifier 
110. Steps for processing requests 108 under such scenarios according to some 
embodiments of the present invention are illustrated by Figure 5. The server 108 receives 
201 a request 108, retrieves 203 stored license information 101 concerning the user 102 
and compares 205 the received hardware configuration identifier 1 10 to the stored 
identifier 1 10. Responsive to received hardware configuration identifier 1 10 neither 
being acceptably similar nor identical to the stored hardware configuration identifier 110, 
the server 108 determines 501 tiiat tiie user is not licensed to run tiie software program, 
and returns 503 software license information 101 so indicating to the cUent 103. 

[0047] Returning to Figure 1 , note that in one embodiment, whether the user 
102 is or is not licensed to run the software program, the server 108 retums software 
license information 101 concerning the user 102 to the client 103. Where the server 108 
determines that the user 102 is licensed to access a requested server 108 provided feature 
105 of the software program, the server 108 provides the requested feature 105 of the 
software program to tiie client 103. Where the server 108 determines tiiat the user 102 is 
not licensed to access a requested featiire 105 of tiie software program, tiie server 108 
does not provide tiie requested feature 105 of tiie software program to tfie client 103. The 
chent 103 can respond accordingly in various ways as desired, for example by not 
allowing tiie user 102 to run tiie software program. Client 103 side processing is 
discussed in greater detail below. 

[0048] Turning to Figure 6A, this specification will now explain client 1 03 
side processing according to some embodiments of the present invention, in which the 
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client 103 makes a supplemental check that the user 102 is licensed to run the software 
program on the computer 104 on which the program is currently executing (it is to be 
understood that not all embodiments of the present invention make such supplemental 
checks). Figure 6A illustrates high level steps for client 103 side processing according to 
some such embodiments of ttie present invention. The steps illustrated at a high level in 
Figure 6A are described in detail in conjunction with Figures 6B through 9. 

[0049] Figure 6B illustrates steps for cUent 103 side processing where the 
current date 1 13 is sufficiently later than the received hardware configuration identifier 
modification date 111, according to some embodiments of the present invention. The 
client 108 sends 601 requests 107 to a server 108 to access features 105 of a software 
program, as explained above. In response to a request 107, the client receives 603 current 
user software Ucense information 101 fi-om the server 108. If the server 108 determines 
that the user 102 is Ucensed to run the software program, the license information 101 
includes a hardware configuration identifier 110 and, in some embodiments, its 
associated modification date 111. Recall that the hardware configuration identifier 1 10 
returned by the server 108 maps to the hardware profile of the computer 104 on which the 
server 108 has most recently determined that the user 102 is autiiorized to run the 
software program, and that the associated hardware configuration identifier modification 
date 1 1 1 maps to the date on which the saver 108 detected that the hardware profile of 
that computer 104 had been most recently modified. When the server 108 determines 
that the user 102 is Ucensed to access the requested feature 105, the server 108 returns the 
requested feature 105 as well, where the feature 105 in question is one provided by the 
server 108 (as illustrated in Figure 1). 
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[0050] When the client receives 603 software license information 101 
including a hardware configuration identifier 1 10 firom the server 108, the client 103 
proceeds to use techniques that will be readily apparent to one of ordinary skill in the art 
to determine the current hardware configuration of the user's 102 computer 104, and to 
create 605 a corresponding current hardware configuration identifier 1 10. The client 103 
compares 607 the current hardware configuration identifier 1 10 to the received hardware 
configuration identifier 1 10, in order to determine whether the two hardware 
configuration identifiers 1 10 are acceptably similar, hi some embodiments, where the 
current hardware configuration identifier 1 10 is acceptably similar but not identical to the 
received hardware configuration identifier 1 10, the client compares 609 the received 
hardware configuration identifier modification date 111 with the current date 113 (which 
can be supplied by the server 108 for security purposes), in order to determine whether 
the current date 1 13 is sufficiently later than the received hardware configuration 
identifier modification date 111. If the current date 1 13 is sufficiently later than the 
received hardware configuration identifier modification date 1 1 1, the client determines 
that the detected hardware modification to the computer 104 is legitimate, because the 
hardware profile is still acceptably similar, and the modification occurred an acceptable 
amount of time after the previous modification. In this case, the cHent updates 61 1, 613 
the received software license information 101 concerning the user 102 by replacing the 
received hardware configuration identifier 110 with the current hardware configuration 
identifier 1 10, and by replacing the received hardware configuration identifier 
modification date 1 1 1 with the current date 1 13. The cHent then stores 615 the updated 
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license information 101 (as illustrated in Figure 1), for use in subsequent verifications as 
desired. The client proceeds to allow 617 the user 102 to run the software program. 

[0051] Of course, sometimes the current date 1 1 3 will not be sufficiently 
later than the received hardware configuration identifier modification date 111. Client 
103 side processing under those circumstances according to some embodiments of the 
present invention is illustrated in Figure 7. As described above in conjunction with 
Figure 6B, the client 108 sends 601 requests 107 to the server 108 to access features 105 
of a software program. In response to a request 107, the client receives 603 current user 
software Ucense information 101 &om the server 108. When the cUent receives 603 
software hcense information 101 including a hardware configuration identifier 110 fi-om 
the server 108, the cUent 103 proceeds to create 605 a current hardware configuration 
identifier 1 10 pertaining to the user's 102 computer 104. The cUent 103 compares 607 
the current hardware configuration identifier 1 10 to the received hardware configuration 
identifier 1 10, in order to determine whether the two hardware configuration identifiers 
1 10 are acceptably similar. Where the current hardware configuration identifier 1 10 is 
acceptably similar but not identical to the received hardware configuration identifier 1 10, 
in some embodiments the client compares 609 the received hardware configuration 
identifier modification date 11 1 with the current date 1 1 3. If the current date 1 1 3 is not 
sufficiently later than the received hardware configuration identifier modification date 
1 1 1 , in some embodiments the client 103 determines that the user 1 02 is not authorized to 
run the software program, as illustrated in Figures 6A and 7. In response, in some 
embodunents the client 103 responds by terminating 701 the software program, such that 
the user 102 cannot run the software program, hi other embodiments, the client 103 
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responds in other ways as desired. For example, the dient 103 can display 703 a message 
to the user 102 indicating that the user is not licensed to run the software program. The 
chent 103 can provide 705 the user 102 with an opportunity to purchase a license, for 
example by entering credit card information. The cUent 103 can allow 707 a certain 
number of unlicensed grace uses, or allow 709 unUcensed use for a specific period of 
time. As will be apparent to one of ordinary skill in the relevant art, various possible 
client 103 responses to detected unlicensed use of the software program are possible, all 
of which are within the scope of the present invention. In other embodiments, the client 
allows 617 the user 102 to run the software program, but does not update 61 1, 613 the 
received software Ucense information 101 conceming the user 102 by replacing the 
received hardware configuration identifier 110 with the current hardware configuration 
identifier 1 10, or by replacing the received hardware configuration identifier modification 
date 1 1 1 with the current date 1 1 3 (not illustrated). Such embodiments allow the user 
102 some flexibihty while still ensuring a requisite level of security. 

[0052] Sometimes the client 103 will determine that the received hardware 
configuration identifier 1 10 is identical to the current hardware configuration identifier 
110. Steps for client side processing in these cases according to some embodiments of 
the present invention are illustrated by Figure 8. As describe above, the client 108 sends 
601 requests 107 to the server 108. In response to a request 107, the client receives 603 
current user software license information 101 firom the server 108 including a hardware 
configuration identifier 1 10. The client 103 proceeds to create 605 a current hardware 
configuration identifier 1 10 pertaining to the user's 102 computer 104. The client 103 
compares 607 the current hardware configuration identifier 1 10 to the received hardware 
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configuration identifier 1 10, and determines that the two identifiers 1 10 are identical. In 
response, the client 103 determines that the user is licensed to run the software program, 
and allows 801 the user to do so. 

[0053] Figure 9 illustrates steps for client 103 side processing according to 
some embodiments of the present invention, when the current hardware configuration 
identifier 1 10 created 605 by the cUent 103 is not acceptably similar or identical to the 
hardware configuration identifier 1 10 received 603 fi-om the server. The client 108 sends 
601 requests 107 to the server 108 to access features 105 of a software program. In 
response to a request 107, the client receives 603 current user software Ucense 
information 101 including a hardware configuration identifier 110 firom the server 108. 
The client 103 proceeds to create 605 a current hardware configuration identifier 110 
pertaining to the user's 102 computer 104. The cUent 103 compares 607 the current 
hardware configuration identifier 1 10 to the received hardware configuration identifier 
110, and determines that the current hardware configuration identifier 1 10 is not 
acceptably similar or identical to the received hardware configuration identifier 1 10. In 
response, in some embodiments the chent 103 responds by terminating 901 the software 
program, such that the user 102 cannot run the software program. In other embodiments, 
the cUent 103 responds in other ways as desired. For example, the cUent 103 can display 
903 a message to the user 102 indicating that the user is not licensed to run the software 
program. The cHent 103 can provide 905 the user 102 with an opportunity to purchase a 
Ucense, for example by entering credit card information. The client 103 can allow 907 a 
certain number of unlicensed grace uses, or allow 909 unlicensed use for a specific period 



21 



of time. Of course, in other embodiments the chent 103 can respond in other ways, as 
desired. 

[0054] In some embodiments, the client 103 performs a validation check 
upon starting the software program. It is to be understood that some embodiments of the 
present invention do not perform such a validation check. In one embodiment, the client 
103 makes such a check every time the software program is started, whereas in other 
embodiments such checks are made less than every time, for example according to a 
specific firequency, randomly or according to some other methodology. Figure lOA 
illustrates high level steps for a client 103 performing such a validation check, according 
to some embodiments of the present invention. The steps illustrated at a high level in 
Figure lOA are described in detail in conjunction with Figures lOB through 13. 

[0055] Figure lOB illustrates steps for cHent 103 side processing where the 
current date 1 13 is sufficiently later than the stored hardware configuration identifier 
modification date 111, according to some embodiments of the present invention in which 
the client 103 performs a validation check upon starting the software program. The client 
103 starts 1001 the software program, and creates 605 a current hardware configuration 
identifier 110 pertaining to the user's 102 computer 104. In order to verify that the user 
102 is authorized to run the software program on the computer 104, the client 103 
retrieves 1003 stored software license information 101 concerning the user 102, the 
license information 101 including a hardware configuration identifier 1 10 of the user's 
102 computer 104 and an associated hardware configuration identifier modification date 
111. Such stored information 1 01 can be created when the software program is first 
installed on the computer 104 and the user's 102 Ucense initially verified. As explained 
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above in conjunction with Figure 6B, the stored Ucense information 101 can be updated 
as permissible hardware updates are detected and verified. 

[0056] The client compares 1005 the current hardware configuration 
identifier 1 10 to the retrieved, stored hardware configuration identifier 1 10, to determine 
whether the two are acceptably similar. Responsive to the current hardware 
configuration identifier 110 being acceptably similar but not identical to the stored 
hardware configuration identifier 1 10, in some embodiments the chent compares 1007 
the stored hardware configuration identifier modification date 111 with the current date 
113, which can be supplied by the server 108. Responsive to the current date 113 being 
sufficiently later than the stored hardware configuration identifier modification date 111, 
the client 103 updates 1009, 1011 the stored software license information 101 concerning 
the user 102 by replacing the stored hardware configuration identifier 1 10 with the 
current hardware configuration identifier 110, and replacing the stored hardware 
configuration identifier modification date 111 with the current date 113. Responsive to 
the current date 113 being sufficiently later than the stored hardware configuration 
identifier modification date 1 1 1, the chent 103 proceeds to allow 1013 the user 102 to run 
the software program. 

[0057] Figures 11-13 illustrate chent 103 side processing according to some 
embodiments in which the client 103 performs a vahdation check upon starting the 
software program under other circumstances. Figure 1 1 illustrates steps for such 
processing when the current date 1 13 is not sufficiently later than the stored hardware 
configuration identifier modification date 111. As explained above in conjunction with 
Figure lOB, the client 103 starts 1001 the software program, and creates 605 a current 
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hardware configuration identifier 1 10 pertaining to the user's 102 computer 104. In order 
to verify that the user 102 is authorized to run the software program on the computer 104, 
the chent 103 retrieves 1003 stored software license information 101 concerning the user 
102, the Hcense information 101 including a hardware configuration identifier 110 of the 
user's 102 computer 104 and an associated hardware configuration identifier modification 
date 111. The cUent compares 1005 the current hardware configuration identifier 1 10 to 
the retrieved, stored hardware configuration identifier 1 10, to determine whether the two 
are acceptably similar. Responsive to the current hardware configuration identifier 1 10 
being acceptably similar but not identical to the stored hardware configuration identifier 
1 10, in some embodiments the chent compares 1007 the stored hardware configuration 
identifier modification date 1 1 1 with the current date 113, which can be supplied by the 
server 108 as described above . As illustrated by Figures 1 OA and 1 1, responsive to the 
current date 1 13 not being sufficiently later than the stored hardware configuration 
identifier modification date 1 1 1, in some embodiments the client 103 responds by 
temiinating 1 101 the software program, such that the user 102 cannot run the software 
program. In other embodiments, the chent 103 responds in other ways as desired. For 
example, the chent 103 can display 1 103 a message to the user 102 indicating that the 
user is not licensed to run the software program. The client 103 can provide 1 105 the 
user 102 with an opportunity to purchase a license, for example by entering credit card 
information. The cUent 103 can allow 1 107 a certain number of unlicensed grace uses, or 
allow 1 109 unlicensed use for a specific period of time. As explained above, various 
possible chent 103 responses to detected unUcensed use of the software program are 
possible, all of which are within the scope of the present invention. In other 
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embodiments, the client allows 1013 the user 102 to run the software program, but does 
not update 1009, 101 1 the stored software license information 101 concerning the user 
102 by replacing the stored hardware configuration identifier 110 with the current 
hardware configuration identifier 1 10, or by replacing the stored hardware configuration 
identifier modification date 111 with the current date 113 (not illustrated). Such 
embodiments allow the user 102 some flexibility while still ensuring a requisite level of 
security. 

[0058] Figure 12 illustrates steps for cUent 103 side processing when the 
current hardware configuration identifier 1 10 is identical to the stored hardware 
configuration identifier 110, according to some embodiments of the present invention in 
which the client 103 performs a validation check upon starting the software program. As 
explained above, the cUent 103 starts 1001 the software program, and creates 605 a 
current hardware configuration identifier 110 pertaining to the user's 102 computer 104, 
In order to verify that the user 102 is authorized to run the software program on the 
computer 104, the client 103 retrieves 1003 stored software Ucense information 101 
including a hardware configuration identifier 1 10 of the user's 102 computer 104. The 
client compares 1005 the current hardware configuration identifier 1 10 to the stored 
hardware configuration identifier 110, and determines that the current hardware 
configuration identifier 1 10 is identical to the stored hardware configuration identifier 
110. Responsive to the current hardware configuration identifier 110 being identical to 
the stored hardware configuration identifier 110, the cUent 103 allows 1201 the user 102 
to run the software program. 
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[0059] Figure 13 illustrates steps for client 103 side processing when the 
current hardware configuration identifier 1 10 is not acceptably similar or identical to the 
stored hardware configuration identifier 1 10, according to some embodiments of the 
present invention in which the client 103 performs a validation check upon starting the 
software program. The client 103 starts 1001 the software program, and creates 605 a 
current hardware configuration identifier 1 10 pertaining to the user's 102 computer 104. 
The client 103 retrieves 1003 stored software license information 101 including a 
hardware configuration identifier 1 10 of the user's 102 computer 104, and compares 1005 
the current hardware configuration identifier 1 10 to the stored hardware configuration 
identifier 110. The cUent 103 determines that the current hardware configuration 
identifier 1 10 is neither acceptably similar nor identical to the stored hardware 
configuration identifier 1 10. In response to the current hardware configuration identifier 
1 10 not being acceptably similar to the stored hardware configuration identifier 110 and 
not being identical to the stored hardware configuration identifier 1 10, in some 
embodiments the client 103 terminates 1301 the software program, such that the user 102 
cannot run the software program. In other embodiments, the client 103 responds in other 
ways as desired. For example, the client 103 can display 1303 a message to the user 102 
indicating that the user is not licensed to run the software program. The client 103 can 
provide 1305 the user 102 with an opportunity to purchase a license, for example by 
entering credit card information. The cUent 103 can allow 1307 a certain number of 
unlicensed grace uses, or allow 1309 unlicensed use for a specific period of time. In 
other embodiments the cUent 103 can respond in other ways, as desired. 
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[0060] As will be understood by those familiar with the art, the invention 
may be embodied in other specific forms without departing fi-om the spirit or essential 
characteristics thereof Likewise, the particular naming and division of the modules, 
features, attributes, methodologies, clients, servers and other aspects are not mandatory or 
significant, and the mechanisms that implement the invention or its features may have 
different names, divisions and/or formats. Furthermore, as will be apparent to one of 
ordinary skill in the relevant art, the modules, features, attributes, methodologies, clients, 
servers and other aspects of the invention can be implemented as software, hardware, 
firmware or any combination of the three. Of course, wherever a component of the 
present invention is implemented as software, the component can be implemented as a 
standalone program, as part of a larger program, as a plurality of separate programs, as a 
statically or dynamically linked library, as a kernel loadable module, as a device driver, 
and/or in every and any other way known now or in the fixture to those of skill in the art 
of computer programming. The clients and servers discussed herein can each be 
implemented on a single computing device or on multiple computing devices as desired. 
Wherever fimctionality is described as being performed by a client or by a server, it is to 
be understood that the fimctionality can be provided by one or more components, and that 
these components can have other names as desired. Additionally, the present invention is 
in no way limited to implementation in any specific progranmiing language, or for any 
specific operating system or environment. Accordingly, the disclosure of the present 
invention is intended to be illustrative, but not limiting, of the scope of the invention, 
which is set forth in the following claims. 
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